home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20020314-20021006 / 000403_rayward@metronet.com_Fri Sep 27 15:34:21 EDT 2002.msg < prev    next >
Text File  |  2020-01-01  |  6KB  |  141 lines

  1. Article: 13739 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!panix!bloom-beacon.mit.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail
  3. From: rayward@metronet.com (Ray Ward)
  4. Newsgroups: comp.protocols.kermit.misc,comp.unix.xenix.sco,comp.dcom.modems
  5. Subject: Re: Help!  Trying to send files via serial modem...
  6. Date: 27 Sep 2002 12:19:14 -0700
  7. Organization: http://groups.google.com/
  8. Lines: 122
  9. Message-ID: <7ea6ad1.0209271119.527a46fc@posting.google.com>
  10. References: <7ea6ad1.0209241717.7af4adc8@posting.google.com> <amsde3$d5d$1@watsol.cc.columbia.edu>
  11. NNTP-Posting-Host: 63.99.201.12
  12. Content-Type: text/plain; charset=ISO-8859-1
  13. Content-Transfer-Encoding: 8bit
  14. X-Trace: posting.google.com 1033154355 9692 127.0.0.1 (27 Sep 2002 19:19:15 GMT)
  15. X-Complaints-To: groups-abuse@google.com
  16. NNTP-Posting-Date: 27 Sep 2002 19:19:15 GMT
  17. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13739 comp.unix.xenix.sco:18673 comp.dcom.modems:316244
  18.  
  19. fdc@columbia.edu (Frank da Cruz) wrote in message news:<amsde3$d5d$1@watsol.cc.columbia.edu>...
  20.  
  21. Thanks for the prompt and informative response!  Please see below...
  22.  
  23. > In article <7ea6ad1.0209241717.7af4adc8@posting.google.com>,
  24. > Ray Ward <rayward@metronet.com> wrote:
  25. > : ...my client needs to get data off of a fairly
  26. > : large number (100's) of old Xenix 2.3.2 SysV boxes (i386) to an
  27. > : off-site, modern box to do the checking.  (I'm not sure that all the
  28. > : Xenix boxes are the exact same version.)  Deadline's in October.
  29. > : 
  30. > : My first thought was to automatically send files daily using Kermit
  31. > : from a cron(1) script to a ProCommPlus 4.8 server running in Kermit
  32. > : server mode on the client's Win2000 box.
  33. > :
  34. [snip]
  35. > : ...so I have to find an executable file.
  36. > :
  37. > We have the following SCO Xenix binaries on our FTP site:
  38. >   cku192.sco286                Xenix/286 2.2.1
  39. >   cku190b02.sco386netc-2.2.3   Xenix/386 2.2.3
  40. >   cku192.sco3r2lai             Xenix/386 2.3.3 with Lachman Assoc TCP/IP
  41. >   cku201.sco234                Xenix/386 2.3.4
  42. > Plus some other 2.3.4 variations.  You can find them here:
  43. >   http://www.columbia.edu/kermit/ck80binaries.html
  44. > All of these except the 2.3.4 ones are rather old (C-Kermit version 5 or 6)
  45. > but still much newer than the one you have (version 4).
  46.  
  47. I have downloaded a few of these, but only the older ones are small
  48. enough to transfer on a 1.2Mb floppy.
  49.  
  50. I am now trying to connect using the 21-day Kermit evaluation program,
  51. and I'm still getting the same dropped line.  ProComm Plus is running
  52. in server mode with Kermit as the file transfer protocol.  It looks
  53. like ProComm is dropping the line.
  54.  
  55. > : They already have the ProCommPlus set up.
  56. > : 
  57. > : When I try to connect from the interactive Kermit that I found on one
  58. > : machine (072 24 Jan 89 Xenix/286) it seems to connect...
  59. > :
  60. > Could I get you to upload that binary to our site so we can include it
  61. > with the other Xenix binaries?
  62.  
  63. Sure.  I'll try to get a copy the next time I'm at the client site.
  64. [snip]
  65. > : So, I downloaded the 21-day eval copy of Kermit95 2.0 onto my Win98
  66. > : box and got the same result, with a little more detail:
  67. > : 
  68. > : Kermit session.log:
  69. > : ATQ0V1
  70. > : 
  71. > : OK
  72. > : ATDT9721234567
  73. > : 
  74. > : CONNECT
  75. > : (see garbage...)
  76. > : NO CARRIER
  77. > : 
  78. > : Looks kind of like a baud rate mismatch.   So I set both the PC+ and
  79. > : the Kermit95 to 2400 baud, xon/xoff, 8n1, full duples, 1 check byte. 
  80. > : Didn't help.
  81. > :
  82. > Let's assume your plan is to dial each Xenix box from Windows, log in,
  83. > start Kermit on Xenix, then transfer the file (since having 100 Xenix
  84. > boxes call one Windows box would not make a lot of sense).
  85.  
  86. Actually, I have to dial from the Xenix boxes to the remote server.
  87. The client does not want liability for security problems if we have
  88. to leave the modems in auto-answer mode.  The machines are used for
  89. the daily operations of the customers' businesses all over the country,
  90. and the business owners are not technically savvy.  Getting hacked on
  91. such old equipment would be disasterous, and would practically put them
  92. out of business.
  93.  
  94. I may try to set up Kermit95 in server mode on the file server next week,
  95. or fall back to setting up uucp on the old Xenix boxes and installing
  96. Linux to run uucp on the central server.
  97.  
  98. I have never used Kermit as a server, so that may be interesting...
  99.  
  100. > The Windows box no doubt has an all-singing all-dancing V.Everything modem,
  101. > most likely a Winmodem.  The first thing you need to know about these is
  102. > that you must address them by the Windows name (from the Modems folder in
  103. > the Control Panel), not by their DOS name, such as COM1.  In Kermit 95:
  104. >   set port tapi
  105. >   set speed xxxx
  106. >   dial 9721234567
  107.  
  108. Thanks for the tip on the modem naming convention -- I didn't know that.
  109.  
  110. > But "xxxx" is the kicker.  What should it be?  Does the calling modem
  111. > support protocol negotiation and fallback?  If not, you'll need to set K95's
  112. > interface speed to whatever each Xenix modem supports.   
  113.  
  114. I think that rather than dumbing down the central server's modem, I'll
  115. just let the modems negotiate -- I think all are USR Sportsters, and should
  116. negotiate.
  117.  
  118. > If all the Xenix boxes are different, then getting this to work 100 times
  119. > might be tricky, and in that case maybe it DOES make sense to have the
  120. > Xenixes call Windows after all.  But then you have a couple new problems:
  121. >  1. Windows is not like Xenix -- you can't call it up, get a login:
  122. Don't get me started! ;-)
  123.  
  124. >  2. You'll no doubt have contention, so your calling procedure will have
  125. >     handle the busy-redial scenario (which modern C-Kermit programs are
  126. >     fully capable of, but not the ancient one you have).
  127.  
  128. This is one of the reasons I wanted to use Kermit.  Handling contention
  129. with uucp, and actually confirming complete reception of the file is
  130. something I haven't looked at in more then 15 years!
  131.  
  132. - Ray
  133. rayward@metronet.com
  134.